In general, precise timing systems are used in a wide variety of technical applications, e.g. for the purpose of synchronizing movements of industrial machinery, controlling electric power generation and distribution, synchronizing data flows in telecommunication networks, and generating exact frequencies in radio base stations.
A telecom base station needs synchronization, in order to keep its radio frequencies, and in some cases its real-time clock time, within limits. Traditionally the very precise timing needed is extracted from the data stream received directly from the telecom service provider's communication lines (so-called E1/T1 lines, transferring 8000 frames of data per second with highly accurate frame rate). When the backhaul data traffic uses packet switching, however, this timing source no longer exists.
A GPS receiver can provide the needed synchronization, but only if it can have a sufficiently unobstructed view of the sky. Technologies like Synchronous Ethernet and IEEE 1588 are being considered for providing synchronization through the network, but they require infrastructure investments before they can become realistic and reliable solutions. A further complication is the fact that the telecom service providers need to use infrastructure owned by independent third parties in order to get the full cost advantage of packet-based communication.
It may be necessary to consider a synchronization source that has occasional interruptions; perhaps a combination of two or more such unreliable sources. However, interruptions of base station operation cannot be accepted. An oscillator in the unit is used to drive the local clock that is used as the source of precise frequencies and time, and this oscillator needs to be stable enough not to change frequency too much during synchronization outages. However, highly stable oscillators are expensive.
Atomic clocks are too expensive to be used in small base stations. Instead, the oscillator will use a quartz crystal. The resonant frequency of a quartz crystal changes slowly with age, has some dependence on circuit component values and on driving strength and thus of the supply voltage of the oscillator, and, foremost, it is dependent on temperature.
The most expensive crystal oscillators have their crystal in an oven at regulated constant temperature (oven controlled crystal oscillator, OCXO). The cost of such an oscillator would be a significant part of the total component cost of a small base station, at least for the smallest units, the so-called femtocells, which can serve only a few mobile phones, e.g. in homes.
A less expensive way of increasing oscillator stability is to add circuitry that automatically compensates for changes in the temperature (temperature compensated crystal oscillator, TCXO).
Such temperature compensation is not perfect. Some temperature dependency remains, since the compensation circuitry cannot achieve the exact characteristic that would typically be needed, and since component values are slightly different in different units. Also, aging is still a problem. An ordinary TCXO is therefore not sufficiently stable.
Traditional time distribution uses a clock function that emits a time signal, e.g. a pattern of pulses at regular intervals. This may be accompanied by messages stating the time of day, or equivalent information related to the time signal. Automatic receiving stations can use the time signal and associated data for synchronization of their local clocks.
Communications now increasingly use packet switching, both locally and globally. Data to be transferred is then divided into packets, which are transferred through a network where they are sharing communication links with other traffic and may be delayed by varying amounts of time. The delay variations severely limit the synchronization accuracy unless special methods are used to compensate for them.
The stations may be computers or embedded digital control systems, in which case software in the station can be used for the control of the synchronization process. This software could contain functions for receiving and interpreting the time information and adjusting for any errors or inaccuracies in the data transfer. The software would be responsible for using the received time information for adjusting the setting and the speed of the local clock so that it, as well as possible, is synchronized with the clock that produced the time signal. There would also be software functions that enable the use of the local clock. If there is a local operating system and application programs, these should have the access they need to the local clock time value. There might also be hardware interfaces directly controlled by the local clock, in order to make things happen at more precise time than would be possible with software control. As an example there might be logic circuitry that regenerates a precise time signal, to be used by some local hardware device.
The generation of timing signals and distribution of time via networks is generally applicable in many different technical applications. For example, distribution of time is useful for computers connected to Internet. For some other kinds of network nodes higher accuracy may be needed. One example is in the field of industrial automation, where digitally controlled factory machines may need to work together. Another important area is telecommunication infrastructure, e.g. base stations for mobile telephony, where the different units must be well synchronized, and the radio frequencies they synthesize have to maintain a high accuracy.
For example, consider a “master” unit, equipped with a stable clock, which is perhaps kept accurate by a 1 pps (pulse per second) time signal from a GPS (Global Positioning System) receiver. The master distributes its time information over a packet network, e.g. one using the Internet protocol (IP), to slave units. See FIG. 1.
The Network Time Protocol (NTP) is a standard protocol for such time distribution, and IEEE 1588 is a new standard protocol for more precise time distribution, with the aim of reaching an accuracy of a fraction of a microsecond.
Typical for packet networks is that packets are delayed on the way from sender to receiver. The IEEE 1588 protocol can adjust for this, because it includes a method for measuring the delay time, based on the assumption that it is the same in both directions. There are normally some fluctuations in the delay time, and the control algorithm should compensate for that by implementing a suitable filter characteristic in its control loop, averaging the normal fluctuations and disregarding erroneous data and any occasional abnormal delays that may occur due to e.g. collisions, in a network with intermediate buffering of packets.
The basic synchronization protocol according to IEEE 1588 is schematically illustrated in FIG. 2. The master sends “sync messages” to the slave, each one followed by a “follow-up message”, which includes a “timestamp” that tells the slave what time the master's clock showed when the sync message left the master. The slave timestamps its reception of the sync message, and calculates the difference between the timestamps for reception and transmission. That difference should on average be constant if the slave clock has the same speed as the master clock. If the difference tends to increase or decrease, then the slave should adjust the speed of its clock to counteract the trend, so that the average difference stays constant.
This average difference should be equal to the average delay time. The slave regularly measures the delay time by sending a “delay request” message to the master. The slave timestamps the sending of this message and the master timestamps the reception and the master then sends, in a “delay response” message, its timestamp to the slave. Using these timestamps and those from the sync message transmission and reception, the slave then calculates the sum of the forward and backward delay measurements. Any error in the slave's own clock time gets cancelled out in this calculation, since it would have opposite sign in the two differences that are added together. The sum is then divided by 2 to get a result that would be the actual delay time if the delays, including random fluctuations, were equal in both directions. From this value, which is the desired difference between slave timestamp and master timestamp of each sync message, the previously measured difference for the sync messages should be subtracted in order to obtain the correction that should be added to the slave clock (a positive correction should move its time forward). Usually the corrections are filtered before being applied, in order to even out the random jitter. Also, non-typical values, caused by less common collision events on the network, may be omitted or given lower weight in an averaging filter. If the resulting correction value is negative the slave decrements or retards its clock, and if the correction value is positive it advances its clock, until the average difference for the sync messages becomes equal to the measured difference for the delay request messages (and thereby also to the calculated actual delay time. Two feedback loops are used: One uses only data from the more frequent sync messages and controls the speed of the local clock, essentially trying to keep the measured master-to-slave delay constant. The other, which has a much slower regulation, uses also the less frequent delay request measurements, and controls the phase of the clock, so that it not only has the same speed as the master clock but also shows the same time. Note that changing the speed will in time change the time value compared to the master, and that it may therefore be sufficient to regulate only the speed. A change of the phase is then accomplished by intentionally running the frequency a little too high or too low until the desired phase change has been obtained. This way the local precise time will have the sometimes important property of being monotonous, with a rate of change that can vary only within given limits.
If no special hardware is used, the normally unpredictable delays in the software in master and slave are part of the uncertainty in the over-all path delay. The IEEE 1588 standard describes, however, a way to eliminate that part of the uncertainty, by doing the time stamping at the physical interface. See FIG. 3, which illustrates a layered representation of the master and slave. PHY represents the physical layer and is the electrical interface, typically where analog signals are generated and decoded, respectively, when transmitting and receiving. MAC is the Media Access Control layer, typically a digital hardware subsystem, and the layers above are software. IP (Internet Protocol) and UDP (User Datagram Protocol) are parts of the standard packet communication protocol used e.g. on the Internet, and PTP is the special Precise Time Protocol specified by IEEE 1588. The delay time through the software typically depends on many things, also on unrelated activities that share the processor's time, and will vary unpredictably. Special time stamping hardware registers the time when the SFD (Start of Frame Delimiter) byte passes from MAC to PHY (on transmission) and from PHY to MAC (on reception), and passes the registered timestamps of the IEEE1588 frames up to the PTP protocol software.
In these systems, a clock generally consists of a sufficiently stable oscillator and some kind of hardware counter that is advanced by the oscillator. The oscillator frequency needs to be high in order to obtain the fine precision typical of IEEE1588-based systems: a precision of 10 ns requires a frequency of 100 MHz. The counter can be a simple counter, i.e. one which, for every cycle, changes by 1 in its least significant bit position, arranged to directly show the time in the desired format, e.g. in units of 8 or 16 nanoseconds if a binary nanosecond value is needed.
This could be done by having a controllable oscillator, which could be controlled, by the protocol feedback loop, to have exactly the desired frequency, e.g. 1,000 MHz/8=125 MHz. For this high frequency, the oscillator would probably be replaced by a lower-frequency oscillator followed by a phase-locked loop (PLL). The requirement for variable frequency may increase the cost for low-cost slave systems, and may be difficult to combine with high stability requirements for master clocks.
An alternative, which is used by some equipment makers, is to use a clock signal source consisting of a fixed frequency oscillator, or a combination of a fixed frequency oscillator and a PLL, and let the counter consist of an accumulator register, an adder, and an increment register, and add the increment register contents to the accumulator register in every cycle of the clock signal. This solution is sometimes referred to as an adder-based time generator. The increment value can then be adjusted instead of the oscillator frequency. Very small adjustments must be possible. If an adjustment step down to one billionth (1 nanosecond per second) is required, then the increment must have at least 30 fraction bits, i.e. bit positions to the right of the binary point. A disadvantage is the power consumption of this wide hardware operating at this high frequency.
U.S. Pat. No. 7,024,579 relates to a configurable timing system having a plurality of timing units interconnected via software programmable registers to perform a count operation.
U.S. Pat. No. 7,292,109 relates to an auto-calibrated time base apparatus.
US 2007/0291676 A1 relates to a mobile radio terminal with a system for maintaining autonomous system clock accuracy.
U.S. Pat. No. 6,157,957 relates to a clock synchronization system and method using a continuous conversion function for a communication network.
GB 2,392,353 relates to a method and apparatus for distributing timing data across a packet network.
US 2002/0176194 A1 relates to a high-speed programmable synchronous counter for use in a phase-locked loop.
As mentioned, with IEEE 1588 a time-stamped sync message is received at regular intervals, and these time stamps are used as input to a digital servo loop (PI controller) to synchronize a local clock, thereby producing “precise time” in nanoseconds. The IEEE 1588 protocol allows the measurement of delay time from the “master” (the time server that sends the sync messages) to the “slave”, i.e. to the receiving base station, and that delay time is taken into account when disciplining the local clock.
Synchronization input from GPS is a pulse every second, accompanied with information on “time of day” valid for that pulse. These pulses can be used for disciplining the local clock, using the same or a similar servo loop. Even though the GPS pulses could be used more directly for the purpose described below, the PI controller will improve the result by reducing the effect of jitter in the GPS signal. Therefore it is assumed in the following that a disciplined local precise time clock is used even if/when synchronization is received from GPS. This will also permit the use of other synchronization sources that, like GPS, might have periods of unavailability.
If an E1/T1 line is available—even if not used for the data traffic—then that can be used instead of GPS. Time pulses would then be generated from the E1/T1 signal by logic circuitry, and used to discipline the local precise time clock.
Still another possible source of timing could be a receiver and demodulator for GSM (Global System for Mobile Communications) downlink from the nearest GSM base station (a fixed, bigger base station, i.e. a macrocell, not the small kind of device that would use the local precise time clock that is to be synchronized here). Using this for precise time synchronization would require knowledge of the delay time for the radio waves between transmitter and receiver, i.e. of the distance between them. This would not be required if the synchronization is needed only for keeping correct local oscillator frequency.
When synchronization is received, the local clock has very good long-term stability—it does not drift away, as a local clock would do without synchronization if it were driven by a free-running oscillator.
The oscillator that is used for the local clock can be free-running (always) or it can be controlled by a processor—in this case we assume it is the same processor that handles IEEE 1588 and/or GPS.
In the first case it is common to use the oscillator (perhaps indirectly, via a PLL that increases the frequency) to clock a digital circuit that in each cycle adds the contents of a register to an accumulator register. The accumulator contents represent the precise time. Let's assume this is in nanoseconds (as in the IEEE 1588 standard). The first register contains an increment, which should be equal to the length, in nanoseconds, of each clock period. The increment has many extra fraction bits, and the processor can change it and make the increment slightly more or less than the nominal clock period, in order to compensate for a error in the oscillator frequency an/or to speed up or slow down the clock temporarily to adjust the local precise time. In this way the local “precise time clock” can be disciplined. The servo would thus control the contents of the increment register.
In the second case the servo controls the tuning input of the oscillator, and the increment is fixed.
When synchronization (by any of the methods above) is lost, the servo cannot calculate any error to compensate for. The precise time clock will start to drift away as soon as the oscillator frequency does not have exactly that frequency it must have for the clock to show correct time. If there is a frequency error there will be an increasing time error.